Security architectures for network clients

Enumerates and compares a number of security-enabling architectures for network clients. These architectures, either proposed as methodologies or currently implemented in software and/or hardware, are capable of protecting the client’s software integrity and its environment. The most important methodologies include the reference monitor model, firewalls, and virtual machines. Software implementations are the Java Sandbox, and the code signing concept. Hardware that can be used includes smart cards, and the TCPA/Palladium security initiative. Describes their most important features and provide a review and comparative study based on a number of criteria. Believes that ongoing research can empower these mechanisms for protecting network clients in a more effective way. An earlier version of this work appeared in the Proceedings of the 3rd International Network Conference (INC 2002), 16-18 July, Plymouth, UK, pp. 389-96. that a UNIX system user navigates with the Web browser into a number of Web sites. According to the reference monitor’s policy, described in the SKDB, as a subject, the only privilege the user has is the capability of saving Web pages, files, etc. in the directory `̀ Internet_files’’ of the mounted hard disk (the corresponding object). If a malicious applet is downloaded on the user’s machine and tries to gain root privileges by, e.g. executing a SUID program, it will simply fail since the reference monitor will deny access, according to the previous security policy. The same applies with the user’s mail client. If the user is only allowed to save attachments on the disk storage then a rogue program could not harm the system, as the reference monitor would prevent any compromise. The firewall concept Properly configured firewalls can constitute an effective type of network security. They prevent the dangers of the Internet from spreading into the internal network by restricting access at a centrally managed point. Firewalls are classified into three main categories (Cheswick and Bellovin, 1994): 1 packet filters that drop packets based on their destination address and port; 2 circuit gateways that relay TCP connections; and 3 application-level gateways where specialpurpose code is used for each desired application (making it easy to log and control all incoming and outgoing traffic). Application-level gateways can provide a centralized point for monitoring the behavior of an electronic mail system and they can analyze and record traffic and content looking for information leaks. Their principal disadvantage is the need for a specialized user program for most services provided. Also, the use of such gateways is easiest with applications that make provision for redirection, such as e-mail, otherwise new client programs must be provided. Another category of firewalls, becoming increasingly popular, is the personal firewalls that can be useful for preventing and even detecting potential spyware and also protecting from malicious executables (Ghosh, 2001). However, they cannot help in the detection of spyware that is masquerading in programs that use the network for other legitimate purposes. To recapitulate, firewalls are not panacea, since they must be properly configured and regularly updated as new threats and vulnerabilities are discovered (Zwicky et al., 2000). They offer only one layer of protection and cannot be considered a full security solution since they cannot protect from insider attacks (Garfinkel and Spafford, 2002) and cannot block encrypted information or traffic tunneled via HTTP although some solutions have been provided (Martin et al., 1997). The virtual machine concept A virtual machine is a piece of computer software designed to reproduce a specific set of computer behaviors and capabilities other than the ones native to the computer or operating system on which the software itself is running. Some virtual machines are emulators; others produce behaviors and capabilities of a machine that doesn’t necessarily exist as an actual piece of hardware but may only be a detailed specification. More modern examples include the specification of the Java Virtual Machine (JVM) (Lindhorn and Yellin, 1997) and the common language infrastructure of the Microsoft.NET initiative. These allow diverse computers to run software written to that specification; the virtual machine software itself must be written separately for each type of computer on which it runs. Other virtual machines let one operating system run on top of another on the same machine (VMware Inc., 2000). The virtual machine design has two advantages: 1 system independence, since any application will run the same in any virtual machine, regardless of the hardware and software underlying the system; 2 security, because the virtual machine has no contact with the operating system, hence there is little possibility of a program damaging other files or applications. The virtual machine can be used to sandbox applications since it stands between the real hardware or another operating system layer (the virtual machine is often an operating system). This, of course, has a downside concerning efficiency, because operating system calls and privileged instructions of Figure 1 The reference monitor concept [ 85 ] Victoria Skoularidou and Diomidis Spinellis Security architectures for network clients Information Management & Computer Security 11/2 [2003] 84-91 programs running in a virtual machine have to pass through the virtual machine layer. Thus, virtual machines like JVM and VMware also provide a restricted environment in which programs may operate. Errant applications should only be able to cause damage to the virtual machine, thus leaving the real system intact. Software implementations Here, we present network client security architectures currently implemented in software that allow the secure execution of downloadable executable content (i.e. mobile code). The Java Sandbox The concept of sandbox or software fault isolation was first described in (Wahbe et al., 1993). The Java Sandbox is Java’s security model, by which any untrusted Java applet must abide. It is a technological solution to prevent malicious code behavior, thus protecting a network client from possible attacks. For example, if a user downloads via the Web browser an applet that tries to erase the user’s hard disk, it will fail because the sandbox restricts its operation, since it is untrusted. The Java Sandbox is enforced by three technologies: 1 the bytecode verifier; 2 the applet class loader; and 3 the security manager (McGraw and Felten, 2000). The Java Sandbox is quite complicated but it is one of the most complete existing security models. The problem is that the three technologies comprising the model work in concert to prevent an applet from abusing its restricted privileges. They are highly interdependent and non-overlapping. Because each one provides a different function, a flaw in one can break the whole sandbox (McGraw and Felten, 1997). So, their design must be solid, and their implementations must not be flawed. The complexity of the functions that each technology provides makes a correct implementation a difficult goal to attain. The Java security problems found to date are a direct result of flaws in these functions’ implementations (Ghosh, 1998). The Java security model continued to evolve with new Java releases (Gong et al., 1997). JDK 1.2 introduced a more flexible security model in which the class loader can assign a different security policy to each class as it is loaded and stack inspection (Wallach and Felten, 1998) is used to determine what privileges are enabled. It also introduced the notion of protection domains and the access controller as a more abstract and flexible alternative to the security manager. Code signing Modern component-based software is a lot harder to secure because: 1 one cannot assume that all the modules are trustworthy; 2 one cannot assume that all the modules are written well enough to work in every possible configuration; and 3 the operating system is not there to deal with 1 and 2, since modern components talk to each other directly, not through the operating system, so any built-in safety features simply do not apply. Several general methods for dealing with this security problem have been tried, like code signing. The programmer signs components and the user decides, based on the signatures, which components to allow on the computer. Sun’s Java and Microsoft’s ActiveX controls provide code-signing features. The Java Sandbox very simply and strictly prevents Java applets downloaded from the network from using sensitive system services. The security policy for untrusted applets is black-and-white (Ghosh, 1998): if applets are downloaded across a network connection, they must abide by the strict constraints of the sandbox; if they are loaded from the local file system, they are completely trusted and given free rein of the system, as Java applications do. To provide greater flexibility to run Java applets in a trusted environment, JavaSoft has provided the ability to sign applets using JDK’s 1.1 Crypto API. It provides the ability to digitally sign applets with unforgeable proof of identity (Gritzalis et al., 1998). In this way, applets access system resources based on who signs them. The black-and-white security policy for executing applets in JDK 1.1 changed to a shades-of-gray model in JDK 1.2 where more fine-grained access control is supported. ActiveX is a framework for Microsoft’s software component technology that allows programs encapsulated in units called controls to be embedded in Web pages (Ghosh, 1998). Unlike Java, ActiveX is language independent but platform specific. The controls can be written in several different languages but can be executed only on a 32-bit Windows platform. Since ActiveX controls have the ability to execute much like any other program on a computer, they may be used to forge e-mail and write files (integrity loss), monitor Web usage, send files over the Internet and interact with other programs (threat to privacy and [ 86 ] Victoria Skoularidou and Diomidis Spinellis Security architectures for network clients Information Management & Computer Security 11/2 [2003] 84-91 confidentiality through information leaks), etc. Microsoft’s response to addressing ActiveX technology security problems is Authenticode (Microsoft Corp., 2001). This does not prevent ActiveX controls from behaving maliciously but it can be used to prevent automatic execution of untrusted ones. Authenticode can provide two checks before executing ActiveX controls: it can verify who signs the code (authentication), and if the code has been altered since it was signed (integrity). Authenticode provides verification of the identity of the person who signed the control and integrity checks of the software to ensure it has not been altered since it was signed. However, the signature provides no assurance that the control will not behave maliciously. Authenticode technology works solely on a trust model and there is no middle ground to let the control execute in a constrained environment where it can be observed before granting full access. The key difference in security between ActiveX controls and Java applets is that ActiveX security is based wholly on the trust placed in the code signer, while Java applet security is based on restricting the behavior of the applet (Ghosh, 1998). One is a human judgment-based approach to security, while the other is a technology-based approach using the sandbox solution. Java applets signing has been also introduced by JavaSoft as a policy based on trust and human judgment. Signed applets have the ability to access system resources based on who signed them, but untrusted ones can still execute, albeit with the sandbox limitations. Other techniques for trying to provide proofs in software code include proof carrying code (Necula and Lee, 1996) and efficient code certification described in Kozen (1998). In summary, code signing does prove the integrity and authenticity of a piece of software purchased in a computer store or downloaded over the Internet. But it does not promote accountability, because it is nearly impossible to tell if a piece of software is malicious or will behave in a malicious manner (Garfinkel and Spafford, 2002). Research in certifying software components for security properties has been conducted (Ghosh and McGraw, 1998). Hardware implementations So far, security-enabling architectures that were proposed as methodologies or are based on software implementations were examined. In this section, we describe hardware-based ones. Smart cards A smart card stores and processes information through the electronic circuits embedded in silicon in the plastic substrate of its body. There are two basic kinds of smart cards (Chen, 1998): an intelligent smart card contains a microprocessor and a memory chip and offers read, write, and calculation capability. A memory card contains only a memory chip, is meant only for information storage and can only undertake a predefined operation. Smart cards can carry all necessary functions and information on the card, so they do not require access to remote databases at the time of the transaction. Their benefits of increased storage, security and portability have made them very popular compared with magnetic stripe cards, that are not so secure, require a host system to store and process all data and cannot make data universally accessible (Coleman, 1998). By putting sensitive information like passwords and encryption keys into a central point like the card and, thus, outside of the client’s environment, the client becomes less vulnerable to malicious attacks. Typically any application requiring authentication can benefit from a smart card. Smart cards can be used for authentication and as a secure, convenient portable storage mechanism. On the other hand there also exist problems: if a hacker takes the control of the client he could force the card to do something the client does not want like giving his credit card information to a malicious site (Balfanz and Felten, 1999). Also, since smart cards blindly sign any data that is sent to them the user has no way of verifying that this data is what he wanted to be signed (Freudenthal et al., 2000). In such a case a hacker could modify the signing software so that it makes changes to a document before it is signed. As a result the user may see one document, but sign something else. With the advent of the Java Card (a smart card capable of running Java bytecodes) limitations like the portability of applications and the flexibility of downloading applications into the card are eliminated, since a single Java application can run on all smart cards (Coleman, 1998). Since one of the fundamental problems in securing computer systems is the need for tamper-resistant storage of keys, smart cards can provide this functionality so that the private key of the network client can be placed on it and the access control on the card is offered via a [ 87 ] Victoria Skoularidou and Diomidis Spinellis Security architectures for network clients Information Management & Computer Security 11/2 [2003] 84-91 proper personal identification number (PIN). Smart cards provide also the ability to upgrade security solutions when they become compromised, e.g. if a hacker cracks the security of smart-card enabled digital satellite systems new cardlets (Java Card applications) could be sent. The fact that smart cards now employ public key encryption to both encrypt data and digitally sign messages to provide unforgeable proof of identity, makes them ideal for integrating into them applications like social security card, access control to Web sites or online databases, digital signatures for e-mail and Web transactions, public keys for encrypting data transactions, credit/debit cards, e-cash, etc. (Ghosh, 1998). Smart cards’ importance has been identified by major credit card organizations like Visa, which has recently announced its chip migration plan (Visa International, 2001) involving the substitution of credit cards with new ones with a microchip, more suitable for e-banking and e-commerce applications. Trusted hardware Palladium, which like the chemists, Microsoft calls `̀ Pd’’ in short (Microsoft Corp., 2002), is Microsoft’s implementation of the Trusted Computing Platform Alliance (TCPA) specification. The TCPA is an industry-working group, initially formed by Compaq, HP, IBM, Intel, and Microsoft in October 1999 with the mission to: `̀ . . . create a new computing platform for the next century that will provide for improved trust in the PC platform’’, thus build a trusted computer (TCPA, 2000). TCPA now lists about 200 corporate members and has already published the TCPA Specification, v1.1. Palladium is distinct from TCPA and does not follow the specification exactly. The idea is that a trusted computer can be built where different users on the system have limitations in their abilities and are isolated from each other (compartmentalization). This is impossible to achieve using only software, and Palladium is a combination of hardware and software modules (Schneier, 2002). Palladium and TCPA have some architectural points in common, such as the use of `̀ trusted hardware’’ within a PC in order to establish a root of trust. They both require modifications to existing hardware architecture in order to work and also modifications to software in order to use trust features. As the two initiatives appear to be interrelated, in the rest of the paper we will use the term `̀ TCPA/Palladium’’. TCPA/Palladium requires changes to four parts of the PC hardware: 1 the CPU; 2 the chipset (on the motherboard); 3 the input devices (i.e. mouse, keyboard, etc.); and 4 the video output devices (graphics processor). Additionally, a new component must be added, a tamper-resistant secure cryptographic co-processor, which Microsoft calls SCP or SPP (Schoen, 2002). TCPA/Palladium provides protection against two broad classes of attacks: 1 remote network-mounted attacks (buffer overflows, other programming flaws, malicious mobile code, etc.); and 2 local software-based attacks (e.g. a debugger trying to read a program’s internal state while executing or trying to subvert its policy). Although TCPA/Palladium is a promising effort for providing trusted computing platforms it is not without problems. Threats to privacy, interference with GNU Public License, restriction of fair use rights (ability to copy and use copyrighted material for personal use) and the `̀ First sales doctrine’’ (ability to resell software or a Palladiumequipped computer) have been extensively discussed in the literature (Anderson, 2002; Arbaugh, 2002). Review and comparison After presenting the various types of security-enabling architectures, in this Table I Protection against security threats Leakage Tamperin g Resource stealin g Repudiat ion M alw are User ignorance Refere nce mon itor 3 3 3 3 3 F irew alls 3 3 3 3 3 V irtua l m achines 3 3 3 3 3 Java S andbox 3 3 3 3 3 Code signing 3 Smart cards 3 3 3 3 3 TCPA/Pallad ium 3 3 3 3 3 3 [ 88 ] Victoria Skoularidou and Diomidis Spinellis Security architectures for network clients Information Management & Computer Security 11/2 [2003] 84-91